As collaboration among developers becomes more and more important and indispensable in the development of various kinds of projects, there has been an urgent need to overcome obstacles discouraging people from sharing and reusing what they have created in an effective way.
In the Open Source initiative, developers may contribute their program codes to the public, allowing anyone to incorporate, modify and distribute their codes for study or commercial purposes free of charge, with the aim of advancing technologies. While having achieved considerable success, the Open Source initiative has its own drawbacks which have hindered its further development. Firstly, the use of Open Source code always carries a high risk of code contamination, both in the form of bugs inadvertently created and in the form of virus or worms intentionally produced. Especially when a piece of code has been modified in multiple rounds by different people at different times after it was initially created, it is difficult to identify who is responsible for particular parts of the code and the risk of code contamination becomes even greater. Secondly, because of such a confused state of ownership of Open Source code where the developers' identities are not maintained and thus are not recognizable in the lifecycles of the codes created by them, they lack incentive to share their codes. Thirdly, in such a situation, a piece of code, once created and submitted, is out of the control of its creator, and is subject to any modifications made by anyone. Thus the maintenance (corrections, refinements, enhancements, etc) of the code by the original creator is impossible.
In the software development environment within an enterprise, when team members attempt to share their code in a single project or across projects, they will encounter similar problems which enhance the risk of code contamination, blur responsibilities, increase the difficulty of code maintenance, and make developers reluctant to share their code and use that from other developers. Moreover, in today's software development projects, developers are often required at the end of the production phase to sign a “Certificate of Originality” (COO) stating which parts of the code of the software are their own creation, and which parts are from the Open Source or some other sources; and due to the lack of an effective and reliable mechanism to maintain and track the originality-related information about pieces of code, this process will usually require 1-2 months to complete, which is both burdensome and costly. In addition, improperly maintained originality information about pieces of code can easily be lost during the transfer of people or intellectual assets.
Embedding comments in program source code can partly address the above issues; however, its deficiencies are also very obvious. Comment embedding is not a mechanism specially designed for maintaining originality-related information about source code. Further, whether or not comments are embedded in a piece of code and what any comments contain is entirely determined arbitrarily by the developers themselves. In a recent survey on developers' attitude towards embedding comments, more than half of the surveyed responded that they feel it was bothersome to add comments when writing code and in many times would neglect embedding comments, even if it would be convenient for the future maintenance of the code. In the collaborative development of software projects, a few developers' reluctance to embed comments would make comment embedding as a mechanism of maintaining originality-related information useless to a large extent. Apparently, comment embedding can hardly become an effective or feasible way of maintaining originality-related information about source code.
A SCM (Software Configuration Management, or source control) tool can record developers and revisions during check-in/check-outs in the development of a software project, but it still cannot solve the above issues, because it only maintains the code in a project-centric lifecycle. When the code goes out of a given SCM and is to be reused in some new project, it is difficult for the new team to retrieve the corresponding originality-related information from merely the snapshot of the code.
Thus, there is a need to overcome at least one of the preceding deficiencies and limitations of the prior art.